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1 IMPROVED RELIABILITY AND PERFORMANCE OF SNMP STATUS 

2 THROUGH PROTOCOL WITH RELIABILITY LIMITATIONS 

3 

4 Technical Field 

5 The invention relates to computer networks. More particularly, the invention relates 



6 to improving the reliability of a block transfer of data from a server to a client utilizing 

7 SNMP protocol. 
8 

9 Background Art 



10 Network communications have become a fundamental part of today's computing. It is 

1 1 not uncommon to find two or more computer systems collaboratively working together to 

12 solve problems such as simulations, modeling, forecasting, etc. In fact, these efforts have 

1 3 been so successful, users have been inclined to design and implement larger networks. 

14 As the networks grow larger, increasingly complex, and interface with a variety of 

15 diverse networks, it is the task of a network manager to keep track of the devices on the 

16 networks, to monitor performances and load, diagnose, and correct problems with the 

17 network. 

18 While products that manage homogeneous networks have been available, managing 

19 heterogeneous networks is more complex, and a generally accepted heterogeneous network 

20 management standard did not exist. More recently, Simple Network Management Protocol 

2 1 (SNMP) was developed to provide a heterogeneous network management standard. 

22 SNMP has since become widely accepted as the protocol of choice for managing 

23 Transmission Control Protocol/Internet Protocol (TCP/IP) based network systems. SNMP 
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1 provides network managers the capability to monitor and to control network devices and the 

2 systems which contain SNMP agents, independent of the network topology or complexity. 
The SNMP model of a managed network consists of four types of components: (1) 

4 managed nodes; (2) management stations; (3) management information; and, (4) a 

5 management protocol. The managed nodes can be hosts, routers, bridges, printers or any 

6 other devices capable of communicating status information to the management stations. 

7 Management stations monitor and manage the devices on the network. The management 

8 information contains information on the components of the network. The management 

9 protocol is the format in which this information is communicated to the management system. 
A management station communicates with agents over the network using the SNMP 

1 1 protocol, which allows the management station to query the state of the specified agent's local 

12 objects and modify them as necessary. Therefore, the management station communicates 

13 with the management information bases of each agent. SNMP provides the following four 

14 basic operations for communication: (1) "Get", which is used to retrieve specific 

15 management information; (2) "Get-Next", which is used to retrieve via traversal, 

16 management information; (3) "Set", which is used to manipulate management information; 

17 and, (4) "Trap", which is used to report extraordinary events. By using these operators, the 

18 SNMP manager application may communicate with the agents to identify the agents and to 

19 determine statistical information, such as network traffic flow through a given computer 

20 network. 

21 SNMP messages contain two parts: (1) a message header and (2) a protocol data unit. 

22 The message header comprises a version number and a community name. The community 
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1 name serves to define an access environment for a set of network management stations using 

2 the community name. Additionally, since devices which do not know the proper community 

3 name are precluded from SNMP operations, network managers may also use the community 

4 name as a weak form of authentication. 

5 The data portion of an SNMP message contains the specified SNMP operation, e.g., 

6 "Get", "Get-Next", "Set" or "Trap", as well as the operation's associated data. Fig. 6 depicts 

7 the format for the data portion. The format for a "Get", "Get-Next", or "Set" command 600 

8 includes four fields. The first is a request-ID field 602, which associates requests with 

9 responses. The second is an error status field 604, which indicates an error and an error type. 

10 The third is an error index field 606, which associates the error with a particular variable in 

1 1 the variable bindings. The fourth is a variable bindings field 608, which comprises the data. 

12 Each variable binding associates a particular variable with its current value (except in "Get" 

1 3 and "Get-Next" requests, where the value is ignored). 

14 The format for a "Trap" command 610 includes six fields. The first is an enterprise 

15 field 612, which identifies the type of the object generating the trap. The second is an agent 

16 address field 614, which provides the address of the object generating the trap. The third is a 

17 generic trap type field 616, which provides the generic trap type. The fourth field is a 

18 specific trap type code 618, which provides the specific trap type. The fifth field is a time 

19 stamp field 620, which provides the amount of time that has elapsed between the last network 

20 re-initialization and generation of this trap. The sixth field is the variable bindings field 622, 

2 1 which provides a list of variables containing information of interest about the trap. 
22 
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1 Fig. 7 is a block diagram which illustrates an example of a conventional network 

2 utilizing the SNMP model. Management station 710 controls a plurality of nodes 712a, 712b, 

3 712c which in the figure include two computers 718a, 718b at nodes 712a, 712b, 

4 respectively, and a printer 720 at node 712c. In order for an SNMP management station 710 

5 to manage a node directly, the node must be able to run an SNMP agent. The SNMP 

6 management station and/or agent processes are normally encoded in software. A hardware 

7 implementation for use with certain nodes is also possible. In Fig. 7, the agents 714a, 714b 

8 running on each of the computers 718a, 718b, respectively, would most likely be encoded in 

9 software, whereas the agent 714c for the printer 720 would most likely be a hardware 

10 implementation. 

11 In the SNMP protocol, each SNMP agent may maintain one or more variables that 

12 describe the node's state. These variables are also called "objects" and are identified by an 

13 "Object Identifier" (OID). Related managed objects are grouped together in a data structure 

14 called a "Management Information Base" (MIB). Fig. 8 illustrates two different examples of 

15 SNMP agents. The first agent 830 contains a management information base 832. It is also 

1 6 possible to have multiple management information bases within each agent, as seen in the 

17 second agent 834, which contains management information bases 836 and 838. In addition, 

1 8 each node on the network may have different types of management information bases such as 

1 9 expression MIB 840, 842. 

20 A MIB is maintained by its respective agent which contain OIDs that may describe 

2 1 the current and past states of the node to which it is assigned, as well as provide instructions 

22 to affect the operation of the node. The management stations then carry out the management 
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1 of the network. The management stations have one or more processes that communicate with 

2 the SNMP agents through the network by issuing commands and getting responses. One of 

3 the advantages of this design is much of the complexity of the system is located in the 

4 management stations, rather than in the SNMP agents, allowing the agents to be as simple as 

5 possible in order to minimize their effect on the nodes on which they are running. 

6 In typical communication with an agent, a management station may request multiple 

7 objects with a single "Get" command from a destination agent. However, if one of the 

8 requested objects does not exist on the destination agent, the entire "Get" command fails. 

9 The SNMP protocol cannot guarantee that the retrieved data is reliable. Accordingly, a user 

10 of the management station is not assured of the reliability of the requested objects. 

11 In response to this failure, a user of the management station may decide to issue 

12 single "Get" command on each of the requested objects. However, this increases the time 

13 that a user has to spend in retrieving the requested objections. Moreover, issuing multiple 

14 "Get" commands increases the traffic on the network between the agent and the management 

1 5 station, which may lead to congestion and performance degradation in the network. 
16 

17 Summary of Invention 

18 In accordance with the principles of the present invention, a method for transferring 

19 data between a local device and a remote device over a network where the local device has a 

20 communication architecture having at least an application layer and an interceptor layer. The 

21 method includes receiving by the interceptor layer a first command from the application 

22 layer, the first command specifying a first plurality of identifiers where the first command is 
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1 configured to return an associated value for each identifier of the plurality of identifiers. The 

2 method further includes issuing a second command by the interceptor layer, the second 

3 command specifying a second plurality of identifiers where the second command is 

4 configured to return a next identifier and associated value for each identifier of the another 

5 plurality of identifiers in response to said receiving of the first command. 

6 One aspect of the present invention provides for a system for improving reliability of 

7 data transfer. The system includes an interface, at least one processor, a memory coupled to 

8 the one processor, and an interceptor client. The interceptor client, residing in the memory 

9 and executed by at least one processor, is configured to receive by the interceptor layer a first 

10 command from the application layer, the first command specifying a first plurality of 

11 identifiers where the first command is configured to return an associated value for each 

12 identifier of the plurality of identifiers. The interceptor client is further configured to issue a 

13 second command by the interceptor layer, the second command specifying a second plurality 

14 of identifiers where the second command is configured to return a next identifier and 

1 5 associated value for each identifier of the another plurality of identifiers in response to the 

16 receiving of the first command. 

17 Another aspect of the present invention provides for a computer-readable storage 

1 8 medium on which is embedded one or more computer programs. The one or more computer 

19 programs implements a method for improving reliability of data transfer. The one or more 

20 computer programs include a set of instructions for receiving by the interceptor layer a first 

21 command from the application layer, the first command specifying a first plurality of 

22 identifiers wherein the first command is configured to return an associated value for each 
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1 identifier of the plurality of identifiers, and issuing a second command by the interceptor 

2 layer, the second command specifying a second plurality of identifiers where the second 

3 command is configured to return a next identifier and associated value for each identifier of 

4 the another plurality of identifiers in response to the receiving of the first command. 

5 In comparison to known prior art, certain embodiments of the invention are capable of 

6 achieving certain advantages, including some or all of the following: (1) improvement of the 

7 reliability of the data, or object, transferred; (2) improve network performance; and, (3) 

8 decreased network traffic. 

9 Additional advantages and novel features of the invention will be set forth in part, in 



10 the description which follows, and in part, will become apparent to those skilled in the art 

1 1 upon examination of the following or may be learned by practice of the invention. The 

12 advantages of the present invention may be realized and attained by means of 

13 instrumentalities and combinations particularly pointed in the appended claims. 
14 

15 Description of Drawings 



16 Features and advantages of the present invention will become apparent to those 

17 skilled in the art from the following description with reference to the drawings, in which: 

18 Fig. 1 illustrates a computing environment in which an embodiment of the present 

1 9 invention may be implemented; 

20 Fig. 2 illustrates a tree structure of a MIB database; 

2 1 Fig. 3 illustrates a block diagram of a computing platform in which an embodiment of 

22 the present invention may be implemented; 
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Fig. 4 illustrates a block diagram of a communication architecture of a local device 

2 and a remote device implementing an embodiment of the present invention; 

3 Figs. 5a and 5b together illustrate a flow diagram of an exemplary embodiment of the 

4 present invention; 

5 Fig. 6 illustrates a block diagram of fields of the "Get", "Get-Next", "Set", and "Trap" 

6 commands of the SNMP protocol; 

7 Fig. 7 illustrates a conventional network implementing SNMP protocol; and 

8 Fig. 8 illustrates conventional agents with various types of MIB in the SNMP 

9 protocol architecture. 
10 

H Detailed Description of Preferred Embodiments 

12 For simplicity and illustrative purposes, the principles of the present invention are 

13 described by referring mainly to an exemplary embodiment thereof. Although the preferred 

14 embodiment of the invention may be practiced as a software system, one of ordinary skill in 

15 the art would readily recognize that the same principles are equally applicable to, and can be 

16 implemented in, a hardware system, and that any such variation would be within such 

1 7 modifications which do not depart from the true spirit and scope of the present invention. 

18 In accordance with the principles of the present invention, an interceptor client is 

19 utilized to improve the reliability of data transfer between devices on a network. In 

20 particular, the interceptor client may be configured to monitor transactions between a SNMP 

21 manager application and a SNMP application. The interceptor client may be further 

22 configured to monitor and to identify a "Get" command requesting multiple object identifiers 



1 (OIDs), e.g., OID.a, OID.b, OID.n, from a destination agent. The interceptor client may 

2 be further configured to preprocess the requested OIDs to the nearest possible previous OIDs, 

3 i.e., OID.a-1, OID.b-1, OID.n- 1. The interceptor client may be further configured format 

4 the requested "Get" command as a "Get-Next" command requesting the modified OIDs from 

5 the destination agent. The "Get-Next" command will always retrieve the next value in the 

6 tree of the MIB, regardless of whether or not a valid OID was specified. Accordingly, when 

7 the interceptor client reformats the "Get" command to a "Get-Next" command, the user is 

8 assured of the fact that the requested data will always be returned and is not invalidated by an 

9 error message as with the "Get" command. 

10 Fig. 1 illustrates a block diagram of a computer network 100 in which the present 

11 invention may be practiced. As shown in Fig. 1, the computer network 100, which is 

12 managed using the Simple Network Management Protocol (SNMP) protocol, includes, e.g., a 

13 management station 110, a workstation 120, a bridge 130, a router 140, and a printer 150. 

14 Computer network 100 may also include any number of components, e.g., personal 

15 computers, repeaters, and hubs. The computer network 100 is configured to provide a 

16 communication path for each network device to communicate with other network devices. 

17 The network 102 may be the Internet, Public Switched Telephone Network (PSTN), a local 

1 8 area network or the like. 

19 The SNMP protocol is a client-server-based application protocol. Management 

20 station 1 10 executes a SNMP manager application 115 that communicates with SNMP agent 

21 processes 121, 131, 141, and 151. In particular, the SNMP manager 115 communicates with 

22 one or more of the client processes, i.e., agent process 121 on workstation 120, agent process 
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1 131 on bridge 130, agent process 141 on router 140, and agent process 151 on printer 150 

2 using the SNMP protocol. An agent computer process must be programmed for each of the 

3 computer network elements, and the actions that are to be taken must be specifically 

4 programmed for each computer network element. 

5 Each of agent processes 121, 131, 141, and 151 monitors and controls the operation of 

6 the computer network element containing the agent process, i.e., elements 120, 130, 140, and 

7 150, respectively, by maintaining a data base of objects 122, 132, 142, and 152, respectively, 

8 called the Management Information Base (MIB). The MIB reflects the status of the managed 

9 computer network element. Each of the agent processes 121, 131, 141, and 151 responds to 

10 network management requests from SNMP manager 115. Manager 115 maintains statistics 

1 1 that define the operation of network 100 in MIB 1 12. 

12 Fig. 2 illustrates a MIB database tree for one of the agents in the computer network 

13 100 shown in Fig. 1. The MIB objects are grouped according to functionality and are 

14 categorized in a tree-like data structure. The tree is comprised of a root, branches, and leaf 

15 nodes. The leaf nodes represent MIB object instances and are located at the lowest levels in 

16 the tree. To simplify the traversal process, each branch at the same level in the tree is 

17 assigned a lexicographically ordered number. Thus, each node in the tree is represented by a 

1 8 sequence of period-separated numbers, where each number is associated with a branch level. 

19 The sequence of numbers is known as the "Object Identifier" (OID). From FIG. 2, one can 

20 determine that the object identifier for the system group is "1.3.6.1.2.1.1". 

21 The present invention is platform independent. For example management station 110 

22 may be a personal computer (PC) system running an operating system such as WINDOWS 
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1 95™ or OS/2™, a MAC™, or a UNIX™ based system. However, the invention is not 

2 limited to these platforms. Instead, the invention can be implemented on any appropriate 

3 computer system running any appropriate operating system, such as SOLARIS™, IRIX™, 

4 LINK™, etc. 

5 An exemplary computer system 300 implementing the management station 110 is 

6 shown in Fig. 3. The functions of the management station 110 are implemented in program 

7 code. In particular, the computer system 300 includes one or more processors, such as 

8 processor 302 which provides an execution platform for the management station 110. 

9 Commands and data from the processor 302 are communicated over a communication bus 

10 304. The computer system 300 also includes a main memory 306, preferably Random 

11 Access Memory (RAM), where the software for the management station 110 is executed 

12 from during runtime, and a secondary memory 308. The secondary memory 308 includes, 

13 for example, a hard disk drive 310 and/or a removable storage drive 312, representing a 

14 floppy diskette drive, a magnetic tape drive, a compact disk drive, etc., where a copy of 

15 software for the management station 110 is stored. The removable storage drive 312 reads 

16 from and/or writes to a removable storage unit 314 in a well-known manner. A user 

17 interfaces with the management station 110 with a keyboard 316, a mouse 318, and a display 

18 320. The display adaptor 322 interfaces with the communication bus 304 to receive display 

19 data from the processor 302 and convert the display data into display commands from the 

20 display 320. 

21 Fig. 4 illustrates a management communication architecture 402 that includes an 

22 embodiment of the present invention. As shown in Fig. 4, the SNMP management process 
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1 115 may be configured to have the management communication architecture 402 that 

2 implements an embodiment of an interceptor client 406. In particular, the management 

3 communication architecture 402 includes a SNMP manager application 404, the interceptor 

4 client 406, a SNMP application function 408, a TCP/IP application 410, and a lower layer 

5 412. Further, the agent 117 has an agent communication architecture 420 that includes an 

6 agent application function 422, a SNMP application function 424, a TCP/IP application 426, 

7 and a lower layer application 428. 

8 The SNMP manager application 404 may be configured to issue SNMP commands in 

9 response to user attempts to manage the network 120. A user of the SNMP manager 

10 application 404 initiates an action, e.g., a "Get", "Get-Next", etc., to a destination agent, e.g., 

11 agent 117, and the SNMP manager application 404 calls the associated functions with the 

12 object identifier(s) as a parameter(s) from an "Application Programming Interface" (API) of 

13 the SNMP application function 408 in order to process the requested action. The SNMP 

14 application function 408 may be configured to packetize the request in response to the called 

15 function. The request packet is then encapsulated by the TCP/IP protocol application 410 

16 and transported to the destination agent by the lower layer 408 as TCP/IP data packets. The 

17 agent receives the TCP/IP data packets through the lower layer 428, and the TCP/IP 

18 application 426 reformats the data packets and reassembles the request for the SNMP 

19 application function 424. The agent application 422 responds to the request by performing 

20 the requested action. 

21 The interceptor client 406 may be configured to monitor transactions between the 

22 SNMP manager application 404 and the SNMP application 408. In particular, the interceptor 
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1 client 406 may be configured to monitor and to identify a "Get" command requesting 

2 multiple object identifiers (OIDs), e.g., OID.a, OID.b, OID.n, from a destination agent. 

3 The interceptor client 406 may be further configured to preprocess the requested OIDs to the 

4 nearest possible previous OIDs, i.e., OID.a-1, OID.b-1, OID.n-1. The interceptor client 

5 406 may be further configured to format the requested "Get" command as a "Get-Next" 

6 command requesting the modified OIDs from the agent. 

7 In the SNMP protocol, a "Get-Next" command is used to retrieve the next OID in the 

8 MIB tree of data. As opposed to the "Get" command, which returns requested data, the "Get- 

9 Next" command returns the next OID in the tree and its value. Furthermore, unlike the "Get" 

10 command, the "Get-Next" command does return data for an OID that is too short or is 

11 missing the index part of the OID. For instance, if an OID was misidentified, the "Get" 

12 command would return an error for the misidentified OID. With "Get-Next" command, the 

13 "Get-Next" command still returns an answer, because "Get-Next" command will always 

14 retrieve the next value in the tree of the MIB, regardless of whether or not a valid OID was 

15 specified. Accordingly, when the interceptor client 406 reformats the "Get" command to a 

16 "Get-Next", the user is assured of the fact that the returned data is valid, and thus, highly 

17 reliable. 

18 When the requested data is returned, the retrieved data is in a form of object pairs 

19 since "Get-Next" command returns an OID and a value. The interceptor client 406 compares 

20 each retrieved OID with the associated requested OID. If the OID matches, the requested 

21 OID is updated with the returned data. If the requested OID is less than the retrieved OID, 

22 this implies that the requested OID did not exist on the agent; the requested OID is updated 



1 with a status of non-existent, unavailable, etc. Finally, if the requested OID is greater than 

2 the retrieved OID, this implies the OID arithmetic did not succeed in identifying the previous 

3 OID and a single "Get" command is issued on the requested OID. 

4 Figs. 5a & 5b together illustrate a more detailed flow diagram 500 of an embodiment 

5 of the interceptor client 406 according to the principles of the present invention. As shown in 

6 Fig. 5, the interceptor client 406 is configured to monitor and examine the commands from 

7 the SNMP manager application 404 to the SNMP application 408, in step 502. If, in step 

8 504, the command is any other command than a "Get" command with multiple OIDs, the 

9 application client 406 passes the issued command to the SNMP application 408. Otherwise, 

10 if the issued command is a "Get" command with multiple OIDs, e.g., OID.a, OID.b, 

1 1 OID.n, the interceptor client 406 allocates memory space to store the original multiple OIDs. 

12 For example, the interceptor client 406 may allocate space in the main memory 306 of the 

13 exemplary computer system 300 to create an array to store the original requested OIDs, e.g., 

14 OID.a, OID.b, . . ., OID.n. 

15 The application client 406, in step 506, is further configured to pre-process the 

16 original requested OIDs. In particular, the application client 406 may be configured to take 

17 each requested OID (OID.a, OID.b, OID.n) and attempt to reconfigure the requested OIDs 

18 to the nearest possible previous OID, i.e., OID.a-1, OID.b-1, OID.n-1. It is expected that 

19 the arithmetic on the indices of the requested objects may not achieve the desired subtraction 

20 due to the openness of the SNMP protocol standard. 

21 In step 508, the interceptor client 406 may be further configured to reformat the "Get" 

22 command to a "Get-Next" command using the modified indices in the Request ID 602 field, 
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shown in Fig. 7, of the "Get-Next" command. Subsequently, the interceptor client 406 is 
configured to pass the "Get-Next" command with the modified OIDs to the SNMP 
application 408. The SNMP application 408 may be configured to packetize the "Get-Next" 
command with the modified OIDs in response to the called function. The request packet is 
then encapsulated by the TCP/IP protocol application 410 and transported to the destination 
agent by the lower layer application 412 as TCP/IP data packets. 

In step 510, the destination agent has responded to the request packet and has returned 
the requested data based on the modified OIDs, e.g., OID.a-1, OID.b-1, OID.n-1, through 
the lower layer application 412, TCP/IP application 410 and the SNMP application 408. The 
interceptor client 406 temporarily stores the returned object pairs (OID and value) in a 
temporary memory location. 

In step 512, the OID of one of the returned object pairs is compared against the 
requested OIDs. If the requested OID is the same as the retrieved OID, the requested OID 
value is updated with the instance of the retrieved OID, in step 514. If the requested OID is 
greater than the retrieved OID, this situation indicates that the original OID arithmetic 
performed in step 506 did not succeed in identifying the previous OID. In response, a "Get" 
command with the original requested OID, in step 516. If the requested OID is less than the 
retrieved OID, this situation indicates that the requested OID is does not exist on the 
destination agent, and the interceptor client 406 may be configured to note the status as non- 
existent for the original OID, in step 518. 

In step 520, the interceptor client 406 checks whether there are any more comparisons 
of retrieved OIDs with the requested OIDs. If there are more comparisons, the interceptor 
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1 client 406 returns to step 512; otherwise, the interceptor client 406 may be further configured 

2 to return the results for the requested OIDs, e.g., OID.a, OID.b, OID.n, to the SNMP 

3 manager application 404, in step 522. 

4 While the invention has been described with reference to the exemplary embodiments 

5 thereof, those skilled in the art will be able to make various modifications to the described 

6 embodiments of the invention without departing from the true spirit and scope of the 

7 invention. The terms and descriptions used herein are set forth by way of illustration only 

8 and are not meant as limitations. In particular, although the method of the present invention 

9 has been described by examples, the steps of the method may be performed in a different 

10 order than illustrated or simultaneously. Those skilled in the art will recognize that these and 

1 1 other variations are possible within the spirit and scope of the invention as defined in the 

12 following claims and their equivalents. 
13 
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